Event mechanisms are used in many different computer systems to enable parts of the system to communicate with one another. The terms "event" and "message" are used inconsistently within the literature. As used herein, "event" refers to an incident whose occurrence (and possibly associated data) should be communicated by one part of a computer system to at least one other part of the system to enable the system to operate appropriately. "Event" is sometimes used as an abbreviation for "message describing an event," because communication may be accomplished by transmitting messages between different parts of the system using computer hardware. The hardware is often (but not necessarily) controlled by computer software. The messages transmitted in response to an occurrence of an event are sometimes termed "event notifications."
One familiar approach to the management of event notification utilizes a procedural implementation. The notifying function is made expressly aware of the destination(s) of each event notification. The notifying function makes a specific call to a function in each destination which is responsible for handling the information resulting from the communication. This type of message communication is "tightly coupled" in the sense that the notifying function and the destination function must know of each other at compile time in order for the function calls to be correctly linked together.
In such procedural implementations, the notifying function is forced to make multiple calls (either directly or indirectly) whenever more than one destination needs to receive the message, because one call must be made for each destination. If the messages are intended to arrive at their respective destinations in a particular order, then the notifying function imposes an ordering by calling the destination functions in the desired sequence. This likewise requires express knowledge of the destination functions.
Under another approach to the management of event notification, the messages (or events) are passed through a message queue from the source to the destination. This creates a "loosely-coupled" system in that the sending and receiving functions need not know about each other at compile time, but are linked instead through the message queue. Such a message queue implementation is difficult to use when a message may have multiple destinations because the message queue is typically implemented as a first-in first-out ("FIFO") structure. After the first destination has retrieved the pending message from the queue, the message is either removed, in which case it is no longer available for any other destination, or the message is left in place, in which case it hinders access to subsequent messages.
Under a third approach, event sources and event destinations are loosely coupled through a registration process. This allows several destinations for a single source, but the order in which messages are distributed to multiple destinations is either tightly constrained or unpredictable. Two types of distribution are used, namely "simultaneous" broadcast and distribution according to the order of destination registration.
Under "simultaneous" broadcast, the order of receipt is not important, so it is assumed that all destinations receive the message at the same time. In practice, messages may arrive at different times but the order is not predictable and thus cannot be relied on.
Distribution according to the order of destination registration may result in a First Registered First Notified order or a Last Registered First Notified order. In either case, the order in which different destinations receive a given message depends on the order in which the destinations registered their interest in such messages with some central registry. In situations where the desired order of message receipt does not match the most convenient or established order of registration, tying the event notification order so closely to the registration order is not advantageous.
Yet another approach to event notification utilizes hardware based priority encoders. These encoders, which are tailored for use in prioritizing multiple simultaneous inputs, take a number of inputs of varying degrees of priority. When several inputs are asserted, the encoder resolves to the input which has the highest priority. When that input has been satisfied and is no longer asserted, the priority encoder will again resolve to the input which has the highest priority. This mechanism allows the asserted input with the highest priority to always be identified when multiple inputs are asserted at one time.
However, such special-purpose hardware is expensive, difficult to configure, and difficult to upgrade. Moreover, each piece of hardware is customized, so the hardware introduces many potential failure points which cannot be fixed without hardware changes. Finally, priority encoders are tailored for use in prioritizing simultaneous inputs, not for ordering a sequence of event notifications.
Thus, it would be an advancement in the art to provide a system and method for loosely coupled event notification to multiple destinations which allow the notification order to differ from the registration order.
It would also be an advancement to provide such a system and method which do not require special-purpose hardware such as priority encoders.
It would be an additional advancement to provide such a system and method which support broadcast notification.
Such a method and system for event notification are disclosed and claimed herein.